home *** CD-ROM | disk | FTP | other *** search
- Network Working Group K. Harrenstien (SRI)
- Request for Comments: 953 M. Stahl (SRI)
- Obsoletes: RFC 811 E. Feinler (SRI)
- October 1985
-
- HOSTNAME SERVER
-
-
- STATUS OF THIS MEMO
-
- This RFC is the official specification of the Hostname Server
- Protocol. This edition of the specification includes minor revisions
- to RFC 811 which brings it up to date. Distribution of this memo is
- unlimited.
-
- INTRODUCTION
-
- The NIC Internet Hostname Server is a TCP-based host information
- program and protocol running on the SRI-NIC machine. It is one of a
- series of internet name services maintained by the DDN Network
- Information Center (NIC) at SRI International on behalf of the
- Defense Communications Agency (DCA). The function of this particular
- server is to deliver machine-readable name/address information
- describing networks, gateways, hosts, and eventually domains, within
- the internet environment. As currently implemented, the server
- provides the information outlined in the DoD Internet Host Table
- Specification [See RFC-952]. For a discussion of future developments
- see also RFC-921 concerning the Domain Name System.
-
- PROTOCOL
-
- To access this server from a program, establish a TCP connection to
- port 101 (decimal) at the service host, SRI-NIC.ARPA (26.0.0.73 or
- 10.0.0.51). Send the information request (a single line), and read
- the resulting response. The connection is closed by the server upon
- completion of the response, so only one request can be made for each
- connection.
-
- QUERY/RESPONSE FORMAT
-
- The name server accepts simple text query requests of the form
-
- <command key> <argument(s)> [<options>]
-
- where square brackets ("[]") indicate an optional field. The command
- key is a keyword indicating the nature of the request. The defined
- keys are explained below.
-
- The response, on the other hand, is of the form
-
- <response key> : <rest of response>
-
-
- Harrenstien & Stahl & Feinler [Page 1]
-
-
-
- RFC 953 October 1985
- Hostname Server
-
-
- where <response key> is a keyword indicating the nature of the
- response, and the rest of the response is interpreted in the context
- of the key.
-
- NOTE: Care should be taken to interpret the nature of the reply
- (e.g, single record or multiple record), so that no confusion about
- the state of the reply results. An "ALL" request will likely return
- several hundred or more records of all types, whereas "HNAME" or
- "HADDR" will usually return one HOST record.
-
- COMMAND/RESPONSE KEYS
-
- The currently defined command keywords are listed below. NOTE:
- Because the server and the features available will evolve with time,
- the HELP command should be used to obtain the most recent summary of
- implemented features, changes, or new commands.
-
- Keyword Response
-
- HELP This information.
-
- VERSION "VERSION: <string>" where <string> will be different for
- each version of the host table.
-
- HNAME <hostname>
- One or more matching host table entries.
-
- HADDR <hostaddr>
- One or more matching host table entries.
-
- ALL The entire host table.
-
- ALL-OLD The entire host table without domain style names.
-
- DOMAINS The entire top-level domain table (domains only).
-
- ALL-DOM Both the entire domain table and the host table.
-
- ALL-INGWAY
- All known gateways in TENEX/TOPS-20 INTERNET.GATEWAYS
- format.
-
- Remember that the server accepts only a single command line and
- returns only a single response before closing the connection. HNAME
- and HADDR are useful for looking up a specific host by name or
- address; VERSION can be used by automated processes to see whether a
- "new" version of the host table exists without having to transfer the
-
-
- Harrenstien & Stahl & Feinler [Page 2]
-
-
-
- RFC 953 October 1985
- Hostname Server
-
-
- whole table. Note, however, that the returned version string is only
- guaranteed to be unique to each version, and nothing should currently
- be assumed about its format.
-
- Response Keys:
-
- ERR entry not found, nature of error follows
- NET entry found, rest of entry follows
- GATEWAY entry found, rest of entry follows
- HOST entry found, rest of entry follows
- DOMAIN entry found, rest of entry follows
- BEGIN followed by multiple entries
- END done with BEGIN block of entries
-
- More keywords will be added as new needs are recognized. A more
- detailed description of the allowed requests/responses follows.
-
- QUERY/RESPONSE EXAMPLES
-
- 1. HNAME Query - Given a name, find the entry or entries that match
- the name. For example:
-
- HNAME SRI-NIC.ARPA <CRLF>
-
- where <CRLF> is a carriage return/ linefeed, and 'SRI-NIC.ARPA'
- is a host name
-
- The likely response is:
-
- HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC :
- DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,
- TCP/ECHO,ICMP :
-
- A response may stretch across more than one line. Continuation
- lines always begin with at least one space.
-
- 2. HADDR Query - Given an internet address (as specified in RFC 796)
- find the entry or entries that match that address. For example:
-
- HADDR 26.0.0.73 <CRLF>
-
- where <CRLF> is a carriage return/ linefeed, and '26.0.0.73' is
- a host address.
-
- The likely response is the same as for the previous HNAME request.
-
-
-
-
- Harrenstien & Stahl & Feinler [Page 3]
-
-
-
- RFC 953 October 1985
- Hostname Server
-
-
- 3. ALL Query - Deliver the entire internet host table in a
- machine-readable form. For example:
-
- ALL <CRLF> ;where <CRLF> is a carriage return/linefeed
-
- The likely response is the keyword 'BEGIN' followed by a colon
- ':', followed by the entire internet host table in the format
- specified in RFC-952, followed by 'END:'.
-
- ERROR HANDLING
-
- ERR Reply - may occur on any query, and should be permitted in any
- access program using the name server. Errors are of the form
-
- ERR : <code> : <string> :
- as in
- ERR : NAMNFD : Name not found :
-
- The error code is a unique descriptor, limited to 8 characters in
- length for any given error. It may be used by the access program to
- identify the error and, in some cases, to handle it automatically.
- The string is an accompanying message for a given error for that case
- where the access program simply logs the error message. Current
- codes and their associated interpretations are
-
- NAMNFD Name not found; name not in table
- ADRNFD Address not found; address not in table
- ILLCOM Illegal command; command key not recognized
- TMPSYS Temporary system failure, try again later
-
- REFERENCES
-
- 1. Harrenstien, K., Stahl, M., and Feinler, E., "Official DoD
- Internet Host Table Specification," RFC-952, DDN Network
- Information Center, SRI International, October 1985.
-
- 2. Pickens, J., Feinler, E., and Mathis, J., "The NIC Name Server," A
- Datagram-based Information Utility, RFC-756, Network Information
- Center, SRI International, July 1979.
-
- 3. Postel, J., "Address Mappings," RFC-796, Information Sciences
- Institute, University of Southern California, Marina del Rey,
- September 1981.
-
- 4. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
- Information Sciences Institute, University of Southern California,
- Marina del Rey, October 1984.
-
-
- Harrenstien & Stahl & Feinler [Page 4]
-
-
-
- RFC 953 October 1985
- Hostname Server
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Harrenstien & Stahl & Feinler [Page 5]
-
-